FIG. 1 illustrates a database DB, which contains data units 3, which, for simplicity, are shown organized into rows R1, R2, . . . RN and columns C1, C2, . . . CM. Users can query the database, by commanding a database management system to retrieve a specified collection of the data units.
For example, assume that the database is a nationwide telephone directory. A user may issue a query requesting retrieval of all telephone numbers assigned to parties named Miller, who live on Main Street. The management system will return these telephone numbers to the user.
In many situations, it is convenient for users of the database DB to deal with a subset of the database, rather than with the database itself. These subsets are termed "views." Continuing the example given above, one view may contain all telephone data within the state of New Jersey. If the user issues the same query identified above, but to this view instead of to the database as-a-whole, only telephone numbers in New Jersey would be retrieved.
Two types of view are commonly used. In one type, queries examine the data contained within the database, and computes the query on-the-fly. In the example given above, only New Jersey data would be examined.
In this type of view, the query software involved is somewhat more complicated, and if the view is defined in terms of a particular type of operation, termed a "join," then queries will run more slowly against this type of view than they would if the data were structured as in the view tuple. However, this disadvantage is offset by the fact that the query command is simpler for the user to formulate. Also, this type of view facilitates storing data in a normalized fashion, thereby removing update anomalies.
In using this type of view, the user specifies the view to be queried, and formulates a query. The user need not be concerned with the details of where the New Jersey data is located, or how it is represented, within the database DB. The query software deals with the location and representation.
The other type of view is termed a materialization of the view. In this type of view, the reformulated data corresponding to the view is actually copied into another storage location, which may be another location within the database, or a location outside the database. Users can query this materialization, independent of other users who query the database itself. Views V1-V3 represent materialized views. The hatched data items are copied into the storage locations, as indicated by the arrows.
However, the use of materialized views can create its own problem. If changes occur to the data items 3 within the database, then the copies of these data items contained in the views V1-V3 will not necessarily correspond to the hatched original data items. Consequently, a user of a view may read data which is not current, and if the user reads multiple data items, the items may be mutually inconsistent.
One solution to this problem is to update the views whenever a change occurs in a data item 3. However, this solution imposes undesired overhead upon the system, and slows data retrieval by users. Consequently, it will often be desirable to defer view updates until a later time.